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(54) Location-dependent user interface 

(57) A method is provided of adapting a user inter- 
face to the user's current situation. The method involves 
a user specifying a home-area interface (83), for exam- 
ple, a web browser home page, and an "away" interface 
(84). When the user connects to a network (10) using a 
device (20) and calls up his/her browser home page, a 
determination is made of the location of the device in 
order to decide which version of the home page is to be 
served back to the user device by the home-page server 



of the user. In a preferred embodiment, the "away" home 
page (84) includes specific types of local data of interest 
to the user (such as best local restaurants). When asked 
to provide the "away" home page, the home-page server 
uses this information to find the URLs of local special 
interest web sites ( 1 22) carrying the relevant type of da- 
ta, the server inserting these URLs in the "away " home 
page (84) before providing it to the user device (20) con- 
cerned. 
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Description 

Field of the Invention 

[0001] The present invention relates to location-de- 
pendent user interface presented, for example, to the 
user of a mobile entity that has internet connectivity via 
a cellular radio infrastructure. 

Background of the Invention 

[0002] The preferred embodiments of the invention to 
be described hereinafter are intended for use by mobile 
devices (as well as other devices) that have internet 
connectivity via a mobile radio infrastructure, the devic- 
es determining their location by methods associated 
with this infrastructure. Therefore, in order to facilitate 
an understanding of the present invention, a brief review 
is given below, with reference to Figures 1 to 6, of a typ- 
ical mobile radio infrastructure and of various arrange- 
ments for location determination. 
[0003] Communication infrastructures suitable for 
mobile users (in particular, though not exclusively, cel- 
lular radio infrastructures) have now become widely 
adopted. Whilst the primary driver has been mobile te- 
lephony, the desire to implement mobile data-based 
services over these infrastructures, has led to the rapid 
development of data-capable bearer services across 
such infrastructures. This has opened up the possibility 
of many Internet-based services being available to mo- 
bile users. 

[0004] By way of example, Figure 1 shows one form 
of known communication infrastructure for mobile users 
providing both telephony and data-bearer services. In 
this example, a mobile entity 20, provided with a radio 
subsystem 22 and a phone subsystem 23, communi- 
cates with the fixed infrastructure of GSM PLMN (Public 
Land Mobile Network) 10 to provide basic voice teleph- 
ony services. In addition, the mobile entity 20 includes 
a data-handling subsystem 25 interworking, via data in- 
terface 24, with the radio subsystem 22 for the transmis- 
sion and reception of data over a data-capable bearer 
service provided by the PLMN; the data-capable bearer 
service enables the mobile entity 20 to communicate 
with a service system 40 connected to the public Internet 
39. The data handling subsystem 25 supports an oper- 
ating environment 26 in which applications run, the op- 
erating environment including an appropriate communi- 
cations stack. 

[0005] More particularly, the fixed infrastructure 1 0 of 
the GSM PLMN comprises one or more Base Station 
Subsystems (BSS) 11 and a Network and Switching 
Subsystem NSS 12. Each BSS 11 comprises a Base 
Station Controller (BSC) 14 controlling multiple Base 
Transceiver Stations (BTS) 13 each associated with a 
respective "ceir of the radio network. When active, the 
radio subsystem 22 of the mobile entity 20 communi- 
cates via a radio link with the BTS 1 3 of the cell in which 



2 

the mobile entity is currently located. As regards the 
NSS 12, this comprises one or more Mobile Switching 
Centers (MSC) 1 5 together with other elements such as 
Visitor Location Registers 32 and Home Location Reg- 
5 ister 32. 

[0006] When the mobile entity 20 is used to make a 
normal telephone call, a traffic circuit for carrying digi- 
tised voice is set up through the relevant BSS 11 to the 
NSS 12 which is then responsible for routing the call to 
10 the target phone (whether in the same PLMN or in an- 
other network). 

[0007] With respect to data transmission to/from the 
mobile entity 20, in the present example three different 
data-capable bearer services are depicted though other 

is possibilities exist. A first data-capable bearer service is 
available in the form of a Circuit Switched Data (CSD) 
service; in this case a full traffic circuit is used for carry- 
ing data and the MSC 32 routes the circuit to an mter- 
Working Function IWF 34 the precise nature of which 

20 depends on what is connected to the other side of the 
IWF. Thus, IWF could be configured to provide direct 
access to the public Internet 39 (that is, provide func- 
tionality similar to an IAP - Internet Access Provider 
IAP). Alternatively, the IWF could simply be a modem 

25 connecting to a PSTN; in this case, Internet access can 
be achieved by connection across the PSTN to a stand- 
ard IAP. 

[0008] A second, low bandwidth, data-capable bearer 
service is available through use of the Short Message 
30 Service that passes data canied in signalling channel 
slots to an SMS unit which can be arranged to provide 
connectivity to the public Internet 39. 
[0009] A third data-capable bearer service is provided 
in the form of GPRS (General Packet Radio Service 

35 which enables IP (or X.25) packet data to be passed 
from the data handling system of the mobile entity 20, 
via the data interface 24, radio subsystem 21 and rele- 
vant BSS 11, to a GPRS network 17 of the PLMN 10 
(and vice versa). The GPRS network 17 includes a SG- 

40 SN (Serving GPRS Support Node) 18 interfacing BSC 
14 with the network 17, and a GGSN (Gateway GPRS 
Support Node) interfacing the network 17 with an exter- 
nal network (in this example, the public Internet 39). Full 
details of GPRS can be found in the ETSI (European 

45 Telecommunications Standards Institute) GSM 03.60 
specification. Using GPRS, the mobile entity 20 can ex- 
change packet data via the BSS 11 and GPRS network 
17 with entities connected to the public Internet 39. 
[0010] The data connection between the PLMN 10 

so and the Internet 39 will generally be through a firewall 
35 with proxy and/or gateway functionality. 
[0011] Different data-capable bearer services to 
those described above may be provided, the described 
services being simply examples of what is possible. 

55 [0012] In Figure 1 , a service system 40 is shown con- 
nected to the Internet 40, this service system being ac- 
cessible to the OS/application 26 running in the mobile 
entity by use of any of the data-capable bearer services 
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described above. The data-capable bearer services 
could equally provide access to a service system that is 
within the domain of the PLMN operator or is connected 
to another public or private data network. 
[001 3] With regard to the OS/application software 26 5 
running in the data handling subsystem 25 of the mobile 
entity 20, this could, for example, be a WAP application 
running on top of a WAP stack where "WAP" is the Wire- 
less Application Protocol standard. Details of WAP can 
be found, for example, in the book "Official Wireless Ap- 10 
plication Protocol" Wireless Application Protocol Forum, 
Ltd published 1999 Wiley Computer Publishing. Where 
the OS/application software is WAP compliant, the fire- 
wall will generally also serve as a WAP proxy and gate- 
way. Of course, OS/application 26 can comprise other 15 
functionality (for example, an e-mail client) instead of, 
or additional to, the WAP functionality. 
[0014] The mobile entity 20 may take many different 
forms. For example, it could be two separate units such 
as a mobile phone (providing elements 22-24) and a mo- 20 
bile PC (data-handling system 25) coupled by an appro- 
priate link (wireline, infrared or even short range radio 
system such as Bluetooth). Alternatively, mobile entity 
20 could be a single unit such as a mobile phone with 
WAP functionality. Of course, if only data transmission/ 25 
reception is required (and not voice), the phone func- 
tionality 24 can be omitted; an example of this is a PDA 
with built-in GSM data-capable functionality whilst an- 
other example is a digital camera (the data-handling 
subsystem) also with built-in GSM data-capable func- 30 
tionality enabling the upload of digital images from the 
camera to a storage server. 

[0015] Whilst the above description has been given 
with reference to a PLMN based on GSM technology, it 
will be appreciated that many other cellular radio tech- 35 
nologies exist and can typically provide the same type 
of functionality as described for the GSM PLMN 10. 
[0016] Recently, must interest has been shown in "lo- 
cation-based", "location-dependent", or "location- 
aware" services for mobile users, these being services 40 
that take account of the current location of the user (or 
other mobile party). The most basic form of this service 
is the emergency location service whereby a user in 
trouble can press a panic button on their mobile phone 
to send an emergency request-for-assistance message 45 
with their location data appended. Another well known 
location-based service is the provision of traffic and 
route-guiding information to vehicle drivers based on 
their current position. A further known service is a "yel- 
low pages" service where a user can find out about 50 
amenities (shops, restaurants, theatres, etc.) local to 
their current location. The term "location-aware servic- 
es" will be used herein to refer generically to these and 
similar services where a location dependency exists. 
[0017] Location-aware services all require user loca- 55 
tion as an input parameter. A number of methods al- 
ready exist for determining the location of a mobile user 
as represented by an associated mobile equipment. Ex- 



ample location-determining methods will now be de- 
scribed with reference to Figures 2 to 5. As will be seen, 
some of these methods result in the user knowing their 
location thereby enabling them to transmit it to a loca- 
tion-aware service they are interested in receiving, 
whilst other of the methods result in the user's location 
becoming known to a network entity from where it can 
be supplied directly to a location-aware service (gener- 
ally only with the consent of the user concerned). It is to 
be understood that additional methods to those illustrat- 
ed in Figures 2 to 5 exist. 

[0018] As well as location determination, Figures 2 to 
5 also illustrate how the mobile entity requests a loca- 
tion-aware service provided by service system 40. In the 
present examples, the request is depicted as being 
passed over a cellular mobile network (PLMN 10) to the 
service system 40. The PLMN is, for example, similar to 
that depicted in Figure 1 with the service request being 
made using a data-capable bearer service of the PLMN. 
The service system 40 may be part of the PLMN itself 
or connected to it through a data network such as the 
public Internet. It should, however, be understood that 
infrastructure other than a cellular network may alterna- 
tively be used for making the service request 
[0019] The location-determining method illustrated in 
Figure 2 uses an inertia! positioning system 50 provided 
in the mobile entity 20A, this system 50 determining the 
displacement of the mobile entity from an initial refer- 
ence position. When the mobile entity 20A wishes to in- 
voke a location-aware service, it passes its current po- 
sition to the corresponding service system 40 along with 
the service request 51. This approach avoids the need 
for an infrastructure to provide an external frame of ref- 
erence; however, cost, size and long-term accuracy 
concerns currently make such systems unattractive for 
incorporation into mass-market handheld devices. 
[0020] Figure 3 shows two different location-deter- 
mining methods both involving the use of local, fixed- 
position, beacons here shown as infra-red beacons IRD 
though other technologies, such as short-range radio 
systems (in particular, "Bluetooth" systems) may equally 
be used. The right hand half of Figure 3 show a number 
of independent beacons 55 that continually transmit 
their individual locations. Mobile entity 20B is arranged 
to pick up the transmissions from a beacon when suffi- 
ciently close, thereby establishing its position to the ac- 
curacy of its range of reception. This location data can 
then be appended to a request 59 made by the mobile 
entity 20B to a location-aware service available from 
service system 40. A variation on this arrangement is 
for the beacons 55 to transmit information which whilst 
not directly location data, can be used to look up such 
data (for example, the data may be the Internet home 
page URL of a store housing the beacon 55 concerned, 
this home page giving the store location - or at least 
identity, thereby enabling look-up of location in a direc- 
tory service). 

[0021] In the left-hand half of Figure 3, the IRB bea- 
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cons 54 are all connected to a network that connects to 
a location server 57. The beacons 54 transmit a pres- 
ence signal and when mobile entity 20C is sufficiently 
close to a beacon to pick up the presence signal, it re- 
sponds by sending its identity to the beacon. (Thus, in 
this embodiment, both the beacons 54 and mobile entity 
20C can both receive and transmit IR signals whereas 
beacons 55 only transmit, and mobile entity 20B only 
receives, IR signals). Upon a beacon 54 receiving a mo- 
bile entity's identity, it sends out a message over network 
56 to location server 57, this message linking the identity 
of the mobile entity 20C to the location of the relevant 
beacon 54. Now when the mobile entity wishes to invoke 
a location-aware service provided by the service system 
40, since it does not know its location it must include it's 
identity in the service request 58 and rely on the service 
system 40 to look up the current location of the mobile 
entity in the location server 57. Because location data 
is personal and potentially very sensitive, the location 
server 57 will generally only supply location data to the 
service system 40 after the latter has produced an au- 
thorizing token supplied by the mobile entity 20B in re- 
quest 58. It will be appreciated that whilst service system 
40 is depicted as handling service requests form both 
types of mobile entity 20 B and 20C, separate systems 
40 may be provided for each mobile type (this is likewise 
true in respect of the service systems depicted in Fig- 
ures 4 and 5). 

[0022] Figure 4 depicts several forms of GPS loca- 
tion-determining system. On the left-hand side of Figure 
4, a mobile entity 20D is provided with a standard GPS 
module and is capable of determining the location of en- 
tity 20D by picking up signals from satellites 60. The en- 
tity 20D can then supply this location when requesting, 
in request 61 , a location-aware service from service sys- 
tem 40. 

[0023] The right-hand side of Figure 4 depicts, in re- 
lation to mobile entity 20E, two ways in which assistance 
can be provided to the entity in deriving location from 
GPS satellites. Firstly, the PLMN 10 can be provided 
with fixed GPS receivers 62 that each continuously keep 
track of the satellites 60 visible from the receiver and 
pass information in messages 63 to local mobile entities 
20E as to where to look for these satellites and estimat- 
ed signal arrival times; this enables the mobile entities 
20E to substantially reduce acquisition time for the sat- 
ellites and increase accuracy of measurement (see "Ge- 
olocation Technology Pinpoints Wireless 911 calls with- 
in 15 Feet" 1-Jul-99 Lucent Technologies, Bell Labs). 
Secondly, as an alternative enhancement, the process- 
ing load on the mobile entity 20E can be reduced and 
encoded jitter removed using the services of network 
entity 64 (in or accessible through PLMN 10). 
[0024] One the mobile unit 20E has determined its lo- 
cation, it can pass this information in request 65 when 
invoking a location-aware service provided by service 
system 40. 

[0025] Figure 5 depicts two general approaches to lo- 



cation determination from signals present in a cellular 
radio infrastructure. First, it can be noted that in general 
both the mobile entity and the network will know the 
identity of the cell in which the mobile entity currently 
5 resides, this information being provided as part of the 
normal operation of the system. (Although in a system 
such as GSM, the network may only store current loca- 
tion to a resolution of a collection of cells known as a 
"location area", the actual current cell ID will generally 
10 be derivable from monitoring the signals exchanged be- 
tween the BSC 14 and the mobile entity). Beyond cur- 
rent basic cell ID, it is possible to get a more accurate 
fix by measuring timing and/or directional parameters 
between the mobile entity and multiple BTSs 13, these 
15 measurement being done either in the network or the 
mobile entity (see, for example, International Applica- 
tion WO 99/04582 that describes various techniques for 
effecting location determination in the mobile and WO 
99/55114 that describes location determination by the 
20 mobile network in response to requests made by loca- 
tion-aware applications to a mobile location center - 
server- of the mobile network). 
[0026] The left-hand half of Figure 5 depicts the case 
of location determination being done in the mobile entity 
25 20F by, for example, making Observed Time Difference 
(OTD) measurements with respect to signals from BTSs 
13 and calculating location using a knowledge of BTS 
locations. The location data is subsequently appended 
to a service request 66 sent to service system 40 in re- 
30 spect of a location-aware service. The calculation load 
on mobile entity 20F could be reduced and the need for 
the mobile to know BTS locations avoided, by having a 
network entity do some of the work. The right-hand half 
of Figure 5 depicts the case of location determination 
35 being done in the network, for example, by making Tim- 
ing Advance measurements for three BTSs 13 and us- 
ing these measurements to derive location (this deriva- 
tion typically being done in a unit associated with BSC 
14). The resultant location data is passed to a location 
40 server 67 from where it can be made available to au- 
thorised services. As for the mobile entity 20C in Figure 
3, when the mobile entity 20G of Figure 5 wishes to in- 
voke a location-aware service available on service sys- 
tem 50, it sends a request 69 including an authorisation 
45 token and its ID (possible embedded in the token) to the 
service system 40; the service system then uses the au- 
thorisation token to obtain the current location of the mo- 
bile entity 20G from the location server 67. 
[0027] In the above examples, where the mobile entity 
50 is responsible for determining location, this will generally 
be done only at the time the location-aware service is 
being requested. Where location determination is done 
by the infrastructure, it may be practical for systems cov- 
ering only a limited number of users (such as the system 
55 illustrated in the left-hand half of Figure 2 where a 
number of infrared beacons 54 will cover a generally 
fairly limited) for location-data collection to be done 
whenever a mobile entity is newly detected by an IRB, 
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this data being passed to location server 57 where it is 
cached for use when needed. 

However, for systems covering large areas with poten- 
tially a large number of mobile entities, such as the Fig- 
ure 5 system, it is more efficient to effect location deter- 
mination as and when there is a perceived need to do 
so; thus, location determination maybe triggered by the 
location server 67 in response to the service request 68 
from the mobile entity 20G or the mobile entity may, im- 
mediately prior to making request 68, directly trigger 
BSC 14 to effect a location determination and feed the 
result to location server 67. 

[0028] Further with respect to the location servers 57, 
67, whilst access authorisation by location-aware serv- 
ices has been described as being through authorisation 
tokens supplied by the mobile entities concerned, other 
authorisation techniques can be used. In particular, a 
location-aware service can be prior authorised with the 
location server in respect of particular mobile entities; in 
this case, each request from the service for location data 
needs only to establish that the request comes from a 
service authorised in respect of the mobile entity for 
which the location data is requested. 
[0029] As already indicated, Figures 2 to 5 depict only 
some examples of how location determination can be 
achieved, there being many other possible combina- 
tions of technology used and where in the system the 
location-determining measurements are made and lo- 
cation is calculated, stored and used Thus, the loca- 
tion-aware service may reside in the mobile entity 
whose location is of interest, in a network-connected 
service system 40 (as illustrated), or even in another 
mobile entity. Furthermore, whilst in the examples of 
Figures 2 to 5, invocation of the location-aware service 
has been by the mobile entity whose location is of inter- 
est, the nature of the location-aware service may be 
such that it is invoked by another party (including, po- 
tentially, the PLMN itself). In this case, unless the invok- 
ing party already knows the location of he mobile entity 
and can pass this information to the location-aware 
service (which may, for example, may be situation 
where the PLMN invokes the service), it is the location- 
aware service that is responsible for obtaining the re- 
quired location data, either by sending a request to the 
mobile entity itself or by requesting the data from a lo- 
cation server. Unless the location server already has the 
needed information in cache, the server proceeds to ob- 
tain the data either by interrogating the mobile entity or 
by triggering infrastructure elements to locate the mo- 
bile. For example, where a location-aware service run- 
ning on service system 40 in Figure 5 needs to find the 
location of mobile 20G, it could be arranged to do so by 
requesting this information from location server 67 
which in turn requests the location data from the relevant 
BSC, the latter then making the necessary determina- 
tion using measurements from BTSs 13. Figure 6 de- 
picts the various possibilities discussed above. 
[0030] Although in the foregoing, the provision of lo- 



cation data through the mobile radio infrastructure to the 
mobile entity has been treated as a service effected over 
a data-capable bearer channel, it may be expected that 
as location data becomes considered a basic element 
5 of mobile radio infrastructure services, provision will be 
made in the relevant mobile radio standards for location 
data to be passed over a signalling channel to the mobile 
entity. 

[0031] The present invention concerns adapting a us- 
10 er interface, such as a browser interface presented on 
a mobile device, to the user's current situation. In this 
respect, it is well known that a use can not only specify 
their own home page design for recall whenever they 
start their web browser, but also that a user can specify 
J5 their preferred interface to a particular service provider. 
[0032] It is an object of the present invention to pro- 
vide an improved method of adapting a user interface 
to the user's current situation. 



[0033] According to the present invention, there is 
provided a method of adapting a user interface to the 
user's current situation, comprising the steps of: 

storing interface specification data for defining at 
least first and second user interface data sets in- 
tended for use in implementing device user inter- 
faces in respective different geographic areas, the 
interface specification data defining for each data 
set a respective set of subjects about which infor- 
mation is to be presented, and 
determining which interface data set is appropriate 
for the current location of a user device, transferring 
the appropriate data set to the user device, and us- 
ing that data set to implement a device/user inter- 
face. 

[0034] By way of example, the first data set could be 
intended for use in implementing a device user interface 
in a home area of a user whilst the second data set could 
be intended for use in implementing a device user inter- 
face in other areas; in this case, the step of determining 
which interface data set is appropriate for the current 
location of a user device would involve determining the 
current location of the user device and comparing it with 
the home area of the user. 

[0035] Preferably, the interface specification data de- 
fines each subject in the set of subjects associated with 
each data set, by one of: 

a specific data item; 
a specific data-item reference; 
a generic topic upon which a search can be con- 
ducted for items to be included in the user interface 
implemented using the data set concerned. 
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Brief Description of the Drawings 

[0036] A method and service-system, both embody- 
ing the present invention, for adapting the user interface 
of a device to the user's current situation, will now be 
described, by way of nonlimiting example, with refer- 
ence to the accompanying diagrammatic drawings, in 
which: 

Figure 1 is a diagram of a known communica- 
tions infrastructure usable for transferring voice and 
data to/from a mobile entity; 
Figure 2 is a diagram illustrating one known 
approach to determining the location of a mobile en- 
tity, this approach involving providing the entity with 
an inertial positioning system; 
Figure 3 is a diagram illustrating another 
known approach to determining the location of a 
mobile entity, this approach being based on prox- 
imity of the mobile entity to fixed-position local bea- 
cons; 

Figure 4 is a diagram illustrating a further 
known approach to determining the location of a 
mobile entity, this approach involving the use of 
GPS satellites; 

Figure 5 is a diagram illustrating a still further 
approach to determining the location of a mobile en- 
tity, this approach being based on the use of signals 
present in a cellular mobile radio communications 
system; 

Figure 6 is a diagram illustrating various dif- 
ferent routes by which location information can be 
provided to a service system; 
Figure 7 is a diagram illustrating how a user 
can specify home and away browser home pages 
for storage at their internet access provider site; 
Figure 8 is a diagram similar to Figure 7 but 
illustrating the provision of the appropriate browser 
home page to a mobile user connected to the inter- 
net via a PLMN; 

Figure 9 is a diagram illustrating the steps in- 
volved in serving the appropriate home page back 
to the requesting mobile device in Figure 8; 
Figure 10 is a diagram similar to Figure 8 but 
illustrating the provision of the user's home pages 
by the IAP service system to a gateway of the 
PLMN, the latter being the user's home PLMN and 
the gateway being responsible for passing the cor- 
rect home page to the mobile device; 
Figure 11 is a diagram similar to Figure 1 0 but 
illustrating the provision of the user's home pages 
to the gateway of a visited PLMN; and 
Figure 12 is a diagram similar to Figure 8 but 
illustrating the retrieval by the IAP service system 
of information elements relevant to the locale of the 
user, thee elements being included in the home 
page served to the user. 



Best Mode of Carrying Out the Invention 

[0037] In the following description given with respect 
to Figures 7 to 12, the PLMN 10 and its means for pro- 

5 viding data-capable bearer services for internet access 
are not shown in detail reasons of clarity; the form of the 
PLMN and how data-capable services are provided are, 
for example, as described above in relation to Figures 
1 to 6. Furthermore, the generalisations discussed 

10 above in relation to the mobile entity 20 and location 
servers apply equally to these elements as participating 
in the embodiments of the invention described below. 
[0038] Figure 7 shows a service system 72 of an In- 
ternet Access Provider IAP providing dial-up access to 

15 the internet 30 for users accessing over PSTN 71 from, 
for example, a home PC 70. In Figure 7, the PC 70 is 
illustrated as connecting to server 40 via PLMN 71 , the 
IAP service system 72, and internet 39 (see dotted line 

100) . The provision of internet access is controlled in 
20 standard manner - for example, when a user uses PC 

70 to dial into interface 73 (a modem bank) of the service 
system 72, an access control block 75 checks the user's 
received details (typically user- input username / pass- 
word, or calling line ID) against the details held for that 
25 user in a user-profile database 76. Assuming this check 
is passed, the user is given access to the internet 39 via 
interface 74. 

[0039] Generally, the IAP provides a set of web pages 
for offering services to the user. When a user connecting 
30 through the IAP service system requests access to any 
of these pages, this request is picked up inside the serv- 
ice system by a filter 77 and diverted straight to the web 
server portion of the service system (see dotted line 

101 ) . The web server portion of system 72 comprises a 
35 store 80 of web files (html files, style-sheet files, images 

files, and script files such as CGI and ASP files), a server 
interface 78, and a script execution environment. 79. 
The server interface 78 receives HTTP requests, ac- 
cesses the relevant file in store 80, and either returns 

40 that file directly to the requesting entity in an HTTP re- 
sponse, or, if the file contains server-side scripts, passes 
it to the execution environment 79 that executes the 
scripts and returns the result to server interface 78 for 
sending to the requesting entity. In Figure 7, element 81 

45 represents the "home page" file of the IAP. 

[0040] The IAP in charge of service system 72 offers 
the user of PC 70 the opportunity to specify a user home 
page for storage in store 80. This is a private home page 
intended for the user rather than a public home page 

50 intended for access by third parties (although the user 
could operate the private home page as a public one). 
The private home page is username / password protect- 
ed but is accessible by the user both over the PSTN 71 
and over the internet 71; password protection is 

55 achieved in standard manner well known to persons 
skilled in the art. The set-up (specification) of the private 
home page is effected through one or more script files 
82 provided by the IAP for this purpose and accessible 



6 



11 



EP 1 139 681 A1 



12 



from the lAP's home page 80. The resultant private 
home page is stored as such in store 80 (or possibly as 
a set of defining parameters in the user's profile held in 
store 76). 

[0041] In accordance with an embodiment of the 5 
present invention, the scripts 82 enable the user to store 
two versions of their private home page, namely a 
"home" private home page 83 intended for use when the 
user is in a home area, and an "away" private home 
page 84 intended for use when the user is away from 10 
their home area. The "home" version 83 may, for exam- 
ple, include links to store websites and event websites 
for stores and events local to the user's home area; the 
"away" version 84 may, for example, includes links to 
map websites, travel websites, currency exchange web- *5 
sites etc. In the present example, it is assumed that all 
the information required for the home and away versions 
is known and is directly incorporated into the home and 
away files 83, 84, these latter being given different 
names; however, as will be seen hereinafter, it is possi- 20 
ble also to specify, by type, information that cannot be 
pre-inserted but must be fetched when needed, such as 
detailed area-specific information. 
[0042] Again, in the present example, the user does 
not pass to the service system 72 location parameters 25 
defining what the user means by their home area - this 
is because, as will be seen, it is the accessing device 
that makes this decision. However, in other embodi- 
ments, it is the service system that determines when an 
accessing device is in the home area, this determination 30 
being made on the basis of a home area definition sup- 
plied by the user. 

[0043] Figure 8 depicts the user requesting access to 
his/her private home page from a mobile entity 20, via 
a data-capable bearer service of PLMN 1 0, gateway 35, 35 
internet 39 and the interface 74 of the user's IAP service 
system 72 (see dotted line 102). The request is gener- 
ated by a program running in a data handling sub-sys- 
tem of the mobile entity 20. This program, more fully de- 
scribed below, serves to request, by file name, one or <o 
other of the private home page versions, these file 
names having been previously entered by the user dur- 
ing a set-up phase for the program. Also previously re- 
corded, is the cell ID of the PLMN cell corresponding to 
the user's home area (this can be captured by requiring 45 
the user to indicate during the set-up phase of the pro- 
gram when the user is at "home" - the program being 
arranged to thereupon capture the current cell ID as de- 
tected by the radio sub-system of the mobile entity 20) 
[0044] Figure 9 depicts the steps involved in request- so 
ing and delivering the appropriate private home page to 
the user of mobile entity 20. The user can preset the 
program to pass directly to an automatic determination 
of the appropriate private home page version (step 87), 
or can have the program first display a selection page 55 
(step 86). In this latter case, the user can choose loca- 
tion-based automatic page selection or can specify ei- 
ther the "home" or "away" page versions as being re- 



quired, thereby by-passing the location-based determi- 
nation effected by step 87. If the user chooses automatic 
page selection or if this was preset, then step 87 is ef- 
fected in which the program compares the current cell 
ID as provided by the radio sub-system of mobile entity 
20, with the stored cell ID corresponding to the user's 
home area; if the cell IDs match, the home private home 
page is to be requested, otherwise the "away" private 
home page is requested. The actual sending of the re- 
quest for the appropriate home page, as specified in 
step 86 or determined in step 87, is effected in step 88 
by sending the relevant file name to the IAP service sys- 
tem, together with usema me/password information (or 
whatever other information may be required for access 
authorisation to the private home page of the user). 
Steps 86, 87 and 88 are all carried out in mobile entity 
20. The request is received by the IAP service system 
72 which returns the appropriate private home page. 
The private home page file is received by the mobile en- 
tity and displayed (step 89). It will be appreciated that 
the above process can be implemented using WAP with 
appropriate scripts. 

[0045] Although in the foregoing the automatic deter- 
mination as to which version of the private home page 
should be provided, was effected in the mobile entity on 
the basis of cell ID, a number of other possibilities exist 
both with respect to the parameter to be used forjudging 
location and where the determination is made. Thus, in- 
stead of using cell ID as a location indicator, a more pre- 
cise measure could be made using any of the tech- 
niques described in the introductory portion of the 
present specification; for example, location information 
could be provided by a location server associated with 
the PLMN 1 0 (c.f. location server 67 of Figure 5). Where 
relatively accurate location information is available, the 
home area of a user can be specified as an area of given 
radius centred on a specified location such as the user's 
physical home (again, this location can be captured by 
appropriate triggering of the mobile entity to determine 
its location whilst at the home location, for example, by 
sending a request to a location server). As regards 
where version determination is done, it could be effected 
at the IAP service system 72 on the basis of the location 
of the mobile entity reported to it by the entity itself, or 
as obtained from a location server (with the specific or 
prior authorisation of the user). Furthermore, as will be 
seen below in relation to the Figure 10 embodiment, the 
version determination can be done by an intermediate 
entity such as gateway 35. Where version determination 
is not effected in the user device (entity 20), the latter 
simply requests its private home page as identified by 
a single name; the file pointed to by this name will gen- 
erally be a script file for bringing about version determi- 
nation and page delivery (alternatively, the receiving 
system could be arranged to recognise the file name 
and trigger appropriate action). 
[0046] Of course, access by the user to his/her private 
home page is not restricted to when the user is using a 
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mobile entity and a PLMN; thus, the user could be ac- 
cessing using a PC connected to the PSTN 71. In this 
latter case, the decision as to whether is in his/her home 
area could be made in the service system 72 simply on 
the basis of calling line ID, it being assumed that if the 
calling line ID does not correspond to the user's normal, 
home, calling ID, then the "away" private home page is 
appropriate. More sophisticated strategies, are, of 
course, possible. It will be appreciated that where ver- 
sion determination is carried out by the service system 
72 rather than by the accessing device itself, then it may 
be necessary to define the user's "home" area in several 
different ways, each appropriate for a different type of 
access network (PSTN, PLMN) since the current loca- 
tion of the accessing device may be determined in terms 
specific to that network. 

[0047] Whilst in the foregoing, only two versions of the 
user's private home page have been used (a "home" 
version and an "away" version), it will be appreciated 
that more than two versions can be used, each associ- 
ated with a particular area. For example, a distinction 
could be made between "away" in a foreign country and 
"away" in the user's home country. Furthermore, the ver- 
sion determination can be influenced by other parame- 
ters additional to location such as, in particular, the type 
of the device being used to access the private home 
page and the capabilities of the access network - thus, 
a much richer home page can be provided for PC-type 
devices having internet access via a corporate LAN, as 
compared to WAP cell phones. Indeed, private home 
page versions can be provided that are suitable for voice 
browsers and other non-visual interface devices (the 
use of such non- visual interfaces is not, of course, re- 
stricted to where they are merely an option amongst vis- 
ual interfaces - all versions of the private home page 
could implement non-visual interfaces, even if the ac- 
cessing device had a visual interface capability). 
[0048] Turning now to Figure 10, in this embodiment, 
the user has specified in his/her user profile held in HLR 
31 ofthe PLMN 10(the user's home PLMN) that the user 
has location- based private home pages held by IAP 
service system 72. Now when the user requests internet 
access from mobile entity 20, the details ofthe user and 
service system 72 are extracted from the user's profile 
and past to the gateway 35 (see arrow 103). Gateway 
35 can now act pre-emptively to load the versions of the 
user's private home page from the service system (see 
request arrow 104 and response arrow 105). Upon the 
user making a request for his/her private home page 
(dotted line 106), gateway traps the request and re- 
sponds itself. 

In the Figure 10 example, the determination of which 
version to use is effected by the gateway 35, it being 
authorised to request the location of mobile entity from 
location server 67 (and the home area details having 
been previously provided to the server 35 either from 
service system 72 or HLR 31). The gateway 35 need 
not act pre-emptively to fetch the home page version 



and could wait until requested for the user's private 
home page and then determine which version is re- 
quired before requesting it from service system 72. 
[0049] Figure 11 illustrates the case of the user ac- 

5 cessing via a visited PLMN 10V rather than through the 
user's home PLMN 10H. As with the Figure 10 embod- 
iment, the user's profile held by HLR 31 of the home 
PLMN 10H includes the details of the private home page 
version service. Upon the user accessing the visited 

10 PLMN 10V, the user's profile is obtained from the user's 
home PLMN (for example, using a protocol similar to the 
CAMEL protocol specified by ETSI for GSM networks) 
and passed to the relevant VLR 32 of the visited PLMN. 
Matters now proceed in a manner similar to that de- 

15 scribed for Figure 10 with the gateway 35V of the visited 
network fetching the private homepage versions from 
the service system (arrows 108, 109), obtaining from lo- 
cation server 67 the location of mobile entity 20 when 
the latter requests its private home page (dotted line 

20 1 1 0), and returning the appropriate home page version. 
[0050] Where the user requests his/her private home 
page via an IAP service system which is not its home 
IAP system 72 but which has a cooperation agreement 
with the latter, then an arrangement similar to that de- 

25 scribed for the PLMN 10 in Figure 10 can be used to 
have the visited service system participate in the version 
determination. This is achieved using the RADIUS pro- 
tocol by which cooperating lAPs exchange authorisation 
and billing data, (see RFCs 2138 and 2139 ofthe Inter- 

30 net Engineering Task Force). In particular, when the vis- 
ited service system contacts the system 72 to check the 
user's authorisation, system 72 sends the private home 
page version information to the visited service system 
for the latter to use (the visited system having been pro- 

35 grammed to operate appropriately to provide the version 
determination service). 

[0051] It may also be noted that the user's private 
home page version data need not be stored in the user's 
IAP service system and could for example be held by 

40 gateway 35 or another service system (such as system 
40) independently of IAP system 72. 
[0052] As mentioned above, the private home page 
versions may contain information that cannot be con- 
veniently pre-specified but must be fetched when re- 

45 quired (because, for example, it is information that is 
specific to the current locality ofthe user). Figure 12 de- 
picts such a situation where the user has specified that 
the "away" version ofthe private home page should con- 
tain a best restaurant list and theatre guide for the local- 

50 ity where the user is situated. Such lists can be generally 
termed "Specialist Local Resource Lists" (SLRL) and 
there will generally be a number of websites containing 
such lists for every significant town; these websites are 
depicted as servers 122 in Figure 12. SLRL sites 122 

55 are usually themselves listed in other, more general, 
sites here termed "Local Resource Directories" and de- 
picted as servers 121 in Figure 12. In turn these LRD 
sites will generally be listed in other sites, one such site 
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- a Directory of Local Directories (DoLD) - is shown at 
120 in Figure 12. 

[0053] The user identifies which lists are of interest by 
specifying SLRL category types to the service system 
during the running of the page set-up scripts 82 
[0054] In the present example, it is assumed that the 
version determination is done in service system 72 in 
response to the mobile entity 20 sending a request for 
the user's private home page (see dotted line 114).. This 
request includes as a query string of the request URL, 
the location of the user as determined, for example, by 
a location server of PLMN 1 0 On examining the location 
data, the service system 72 determines that the user's 
"away" home page version is required and that therefore 
it is necessary to obtain the URLs of SLRL websites 122 
for best local restaurants and for local theatre guides. 
The required information is obtained by first contacting 
the DoLD server 120 (line 115) to retrieve the URL of 
the LRD site 121 relevant to the user's current location 
(this latter being passed to the server 120). Thereafter, 
the appropriate LRD site 123 is contacted (line 116) and 
passed the category types of the required specialist lo- 
cal resource lists; LRD responds with the URLs of the 
relevant SLRL sites 122 (these sites are shown hatched 
in Figure 12). These URLs are then incorporated in the 
"away" private home page version which is sent to mo- 
bile entity 20. 

[0055] As well as including URLs of relevant local 
sites, it is also possible to include specific items of infor- 
mation identified generically by the user during page 
set-up (such as the telephone number of the nearest lo- 
cal hospital). Of course, in order to enable such infor- 
mation to be extracted from amongst all the data avail- 
able via the internet, it will generally be necessary for 
the user to identify during the set-up phase a source 
where the information can be found. Thus, the user may 
identify an XML document which by virtue of its struc- 
turing of information permits the relevant data to be ex- 
tracted automatically. 

[0056] It should be noted that although the determi- 
nation of which private home page version should be 
used, and the process of providing location-specific con- 
tent in a private home page version, both require the 
location of the user device (e.g. entity 20) to be known, 
these two processes are largely independent - thus, 
whilst the dame location data could be used for both, 
this is not required. 

[0057] It will be appreciated that may variants are pos- 
sible to the above-described embodiments of the inven- 
tion. 



Claims 

1 . A method of adapting a user interface to the user's 
current situation, comprising the steps of: 

storing interface specification data for defining 



at least first and second user interface data sets 
intended for use in implementing device user 
interfaces in respective different geographic ar- 
eas, the interface specification data defining for 
5 each data set a respective set of subjects about 

which information is to be presented, and 
determining which interface data set is appro- 
priate for the current location of a user device, 
transferring the appropriate data set to the user 
10 device, and using that data set to implement a 

device user interface. 

2. A method according to claim 1, wherein the inter- 
face specification data defines each subject in the 
15 set of subjects associated with each data set, by 
one of: 

a specific data item; 
a specific data-item reference; 
20 - a generic topic upon which a search can be 
conducted for items to be included in the user 
interface implemented using the data set con- 
cerned. 

25 3. a method according to claim 1, wherein the user 
interface specification data is specified at least in 
part by a particular user for use in implementing de- 
vice user interfaces for that user. 

30 4. A method according to any one of claims 1 to 3, 
wherein the first data set is intended for use in im- 
plementing a device user interface in a home area 
of a user and the second data set is intended for 
use in implementing a device user interface in other 
35 areas, the step of determining which interface data 
set is appropriate for the current location of a user 
device involving determining the current location of 
the user device and comparing it with the home area 
of the user. 

40 

5. A method according to any one of the preceding 
claims, wherein the determination of which data set 
to use involves, in addition to making a location-de- 
pendent determination, a determination based on 

45 the type of the device concerned. 

6. A method according to any one of the preceding 
claims, wherein the location-dependent determina- 
tion of which data set to use is made in one of the 

so following: 

the device concerned; 

the entity storing the interface specification da- 
ta; 

55 - an intermediate entity between the device and 
the storing entity. 

7. A method according to any one of the preceding 
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claims, wherein the user interface specification data 
takes the form of a respective web page file for each 
said data set. 

8. A method according to any one of the preceding 5 
claims, wherein the user interface specification data 
comprises data held in a user profile and identifying, 
for each data set, said set of subjects. 



cessed over the internet by a user device either via 
a dial up connection or over the internet to provide 
the data set appropriate for the current location of 
the user device effecting access. 

15. A method according to claim 14, wherein the user 
device is a cell phone effecting access via a mobile 
radio infrastructure and the internet. 



9. A method according to any one of the preceding 10 
claims, wherein at least one data set specifies the 
inclusion of one or more elements relevant to the 
locale of the user device, the method including the 
further sub-step, where said at least one data set is 
determined to be the appropriate data set, of fetch- * 5 
ing said one or more elements in dependence on 

the current location of the device. 

10. A method according to claim 9, wherein a said ele- 
ment comprises one of the following: 20 

a specific data item of local information; 
a hyperlink to a resource containing local infor- 
mation. 

25 

1 1 . A method according to claim 9 or claim 1 0, wherein 
the task of fetching said one or more elements for 
the data set determined as appropriate for the cur- 
rent device location is effected by an intermediate 
entity associated with the locale where the device 30 
is situated, the relevant interface specification data 
being passed to this entity from where it is stored. 

12. A method according to any one of the preceding 
claims, wherein the interface specification data is 35 
held in a store directly accessible to at least one net- 
work, and wherein when the user device is connect- 
ed to a network that is not a said at least one net- 
work, the interface specification data is passed from 
where it is stored to an entity of the network to which *o 
the device is connected, this entity effecting at least 
the sub-step of transferring the appropriate data set 

to the device. 



13. A method according to any one of the preceding 45 
claims, wherein each data set, taken individually, 
relates to a user interface of one of the following 
types: 

a graphical user interface for a web browser; 50 
an audio interface for a web browser. 



14. A method according to any one of the preceding 
claims, wherein the interface specification data is 
stored in an Internet-accessible data store to which 55 
a user has dial-up access for the purposes of spec- 
ifying and/or modifying the interface specification 
data, the interface specification data being ac- 
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